MAC address learning is a service provided by a switch in which MAC address and incoming interface information of each packet is learned locally in a database on the switch. This service can be characterized as a learning bridge, in which a source MAC address of each received packet is stored in a forwarding database so that future packets destined for that address can be forwarded only to the bridge interface on which that address is located. Packets destined for unrecognized addresses are forwarded out every bridge interface. MAC address learning helps minimize traffic on the attached Local Area Networks (LANs). As Ethernet switch sizes evolve, maintenance of the forwarding database becomes significant. For example, Ethernet switches are evolving from single devices to large scale chassis with multiple line cards, blades, modules, “pizza boxes”, etc. As described herein, line cards, blades, modules, “pizza boxes”, etc. all refer to modules in an Ethernet switch, and are collectively referred to herein as line cards. In the single device case, management of the forwarding database is straightforward in that all processing and storage circuitry related to the forwarding database is on the single device and in communication therein. As the large scale chassis develop, individual line cards have their own forwarding databases thereon that are managed, but need to be synchronized with other line cards in the same Ethernet switch.
Conventionally, the multiple line card solution can include a central repository of the forwarding databases for all associated modules that is updated as and when required. However, this solution can cause the scalability issues especially in the case when the MAC address entries need to be synchronized on a periodic basis in case of topologies such as bridging over link aggregation. Multi chassis architectures therefore employ a solution where line cards periodically update the MAC address in the peer line cards by a messaging mechanism. The messaging mechanism may either be implemented in software through some interprocess communications (IPC) mechanism or may be implemented in hardware (e.g., application specific integrated circuit (ASIC), network processor unit (NPU), field programmable gate array (FPGA), etc.). The hardware based periodic synchronization can utilize a lot of hardware bandwidth at timely intervals. As a result of which hardware switching capacity may exceed its total supported capacity and can result in periodic packet drops due to the synchronization. Among other things, this presents a challenge in meeting service layer agreements with end users.